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Remarks 

Claims 1-4 are pending in this application. No claims have been amended. No 
claims have been added or cancelled. 

Specification 

The Specification has been amended to correct typographical errors. 

Rejections under 35 USC 51 03 

The Office Action has rejected claims 1-4 under 35 U.S.C. § 103(a) as being 
unpatentable over Beausoleil et al., U.S. Patent No. 5,551,013 (hereinafter "Beausoleil") 
in view of Austin et a!., U.S. Patent No. 4,885,684 (hereinafter "Austin") and further in 
view of Baker et al., U.S. Patent No. 5,701 ,502 (hereinafter "Baker"). Applicants 
respectfully traverse this rejection. 

"To establish a prima facie case of obviousness, three basic criteria must be met. 
First, there must be some suggestion or motivation, either in the references themselves 
or in the knowledge generally available to one of ordinary skill in the art, to modify the 
reference or to combine reference teachings. Second, there must be a reasonable 
expectation of success. Finally, the prior art reference (or references when combined) 
must teach or suggest all the claim limitations." MPEP 2143. As explained below, 
neither Beausoleil, Austin nor Baker teach or suggest all of limitations of Claim 1 and 
there is no suggestion or motivation to combine Beausoleil with Austin and/or Baker. 

The References Standing Alone Or Wlien Combined 
Do Not Teach Or Suggest All Of The Claim Limitations 

Beausoleil does not teach or suggest a blocking code and in particular decoding 
said blocking code and, in response thereto, blocl^ing transfers between the 
plurality of module processors and said module main memory as recited in claim 1 . 
The Office Action asserts that Beausoleil discloses this limitation relying on two portions 
of the specification. The Office Action first cites to the "Control Store" section of 
Beausoleil. See 12/31/03 Office Action at 3 (citing to Col. 5, line 39 to col. 6, line 18); 
see also 12/21/03 Office Action at 7 (stating "From the rejection, the bits being decoded 
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and being used to allow whether or not memory operations are enabled are meeting 
what is interpreted as blocking code."). This section describes a memory operation bit 
(MOP) that is included in a control word. Beausoleil teaches that if the MOP bit in the 
. control word is "inactive (off)", it signals a logic function emulation operation. If the MOP 
bit in the control word is "active (on)", it signals a memory operation. Col. 6, II. 14-35. In 
other words, this MOP bit controls whether the processors will emulate a logic function 
operation or a memory array operation during execution of that particular control word. 
This MOP bit is not a "blocking code[]" that causes "transfers between the plurality of 
module processors and said module main memory" to be blocked as recited in Claim 1. 

The Office Action also cites to Col. 10, line 64 to Col. 1 1 , line 2 of Beausoleil. All 
this section states, however, is that the user's design is compiled into a series of control 
words. Beausoleil, however, discloses nothing about the insertion of blocking codes, 
which by definition are not part of a user's design. 

Austin does not teach or suggest a blocking code and in particular decoding 
said blocking code and, in response ttiereto, blocking transfers between the 
plurality of module processors and said module main memory to be blocked. The 
Office Action appears to concede this since it merely relies on Austin for the teaching of 
a maintenance bus. See 12/21/03 Office Action at 7 ("What is not explicitly disclosed in 
Beausoleil has been provided by Austin, and that is the use of maintenance facilities 
(bus) to effect fault-prevention and error recovery of modules under execution."). 

Likewise, Baker does not teach or suggest a blocking code and in particular 
decoding said blocl<ing code and, in response thereto, blocking transfers between 
the plurality of module processors and said module main memory. The portions of 
the Baker specification cited in the Office Action (Col. 119, lines 4-53; col. 127, lines 3- 
23) describe a resynchronization process for two or more processors that occurs when 
there is an initial power on, the appearance of a new processor, or a recovery from an 
error condition. Nothing in these portions of Baker teach or suggest "blocking codes" 
that cause "transfers between the plurality of module processors and said module main 
memory" to be blocked. 
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Moreover, neither Beausoleii, Austin nor Baker teach or suggest how data is 
blocked and data is transferred as required by Claim 1. Claim 1 requires that the 
blocking code be decoded. Once the blocking code is decoded. Claim 1 requires that 
, "transfers between the plurality of module processors and said module main memory" 
be blocked and that data be transferred while the blocking condition exists. Neither 
Austin, Beausoleii nor Baker teach or suggest this. In particular, Austin neither teaches 
nor suggests decoding in response to decoding blocking code. First, as discussed, 
Austin does not even teach a blocking code, meaning that Austin cannot teach 
decoding such a code. Moreover, the sections from Austin relied upon in the Office 
Action make no such teachings. In particular, the discussion at columns 6 and 7 in 
Austin only discuss management of the computer system disclosed therein. There is no 
discussion of disabling memory activities while they are updated. The same is true for 
the discussion at columns 12-13 in Austin. Col. 12, line 47 through Col. 13, line 7 relate 
to error correction and fault tolerance. This discussion says nothing about blocking 
codes that disable main data memories while they are updated. 



Like the present invention, Beausoleii relates to the emulation of integrated circuit 
designs. Austin and Baker relate to completely different technologies. Austin relates to 
a distributed data processing network, which has nothing to do with the emulation of 
integrated circuit designs. See, e.g.. Cols. 1-3. Similarly, Baker relates fault-tolerant 
mainframe computer systems, which has nothing to do with the emulation of integrated 
circuit designs. See, e.g., Col. 7, lines 33-38 ("Accordingly, it is intended that the 
present improvement will provide a fault tolerant environment and architecture for a 
normally non-fault-tolerant processing system and operating system without major 
rewrite of the operating system. In the preferred embodiment a model of IBM 
System/88 is coupled to a model of an IBM S/370."). 

There is simply no suggestion or motivation in any of these references to 
combine the references with one another. See MPEP 2143. Furthermore, one of 
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ordinary skill in the art would not look to combine Austin or Baker with Beausoleil since 
each reference relates to unrelated areas of technology. 

Dependent Claims 2-4 

The foregoing arguments apply to Claims 2-4, as they all are dependent on claim 1 . 
Therefore, Applicants respectfully submit that claims 2-4 are allowable as well. 



For the foregoing reasons, the Office Action has failed to establish a prima facie 
case of obviousness under 35 U.S.C. § 103. See MPEP 2143. Therefore, Applicants 
respectfully submit that this application is in condition for allowance, which is 
respectfully requested. Should the Examiner have any questions or comments on the 
application, the Examiner should feel free to contact the undersigned via telephone. 

The Commissioner is authorized to charge any fee which may be required in 
connection with this Amendment to deposit account No. 1 5-0665. 



Orrick, Herrington & Sutcliffe LLP 
4 Park Plaza, Suite 1600 
Irvine, CA 92614-2558 
Tel. 650-614-7622 
Fax: 949-567-6710 



Conclusion 



Respectfully submitted, 

ORRICK, HERRINGTON & SUTCLIFFE LLP 



Dated: August 20, 2004 




Sar^et K. Dutta 
Reg. No. 46,145 
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